Subject:
|
Re: Colinear Vertices
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Fri, 12 Dec 2008 10:55:41 GMT
|
Viewed:
|
12290 times
|
| |
|
|
> Not that I know of. I'll think about adding a page to the LDView web site. (I
> don't think it's really appropriate to add it to ldraw.org, since it's
> LDView-specific.)
It makes sense!
>
> > What about precision in coincidence between conditional lines and matching
> > polygon sides? I have seen _many_ instances where a quad should blend into a
> > primitive thanks to a well placed condline, but doesn't - I guess because of
> > precision issues during primitive scaling/rotation.
>
> The precision is 0.0001. I multiply the coordinate by 10000 and then convert
> the resulting x,y,z values to integers. I then use these integers for all
> equality checks. That does mean that LDraw models using coordinates that result
> in a real-world size greater than around 85 meters could cause wrap-around in my
> calculations, and coordinates that are quite a bit less than that would result
> in sub-ldraw-unit precision problems, but I suspect that the rate of
> false-positives in such situations would be low. I haven't had anyone complain
> about it.
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:
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
>
> I also have a 50 degree threshold: LDView won't smooth two surfaces that have an
> angle between them that is greater than 50 degrees. It probably wouldn't be
> that high except for the fact that low-res studs have 45 degrees between the
> faces, and I added in a little extra leeway. • I have no problem with that - smoothing there would be a bit extreme.
>
> There is one other restriction that is important. I only notice conditional
> lines if BOTH ends match BOTH ends of the polygon edge. So if you use one
> conditional line to span along an edge that has one or more vertices ALONG the
> 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
>
> > 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
This example is a bit farfetched, but I have seen that occur in other instances
where I didn't subparted the part as much as I wanted initially
(http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/50747.dat)
> Given that the official part restrictions
> 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.
> 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...
Philo
|
|
Message has 2 Replies:
 | | Re: Colinear Vertices
|
| (...) 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.) (...) .005. I think I'll set the precision to .01, to hopefully give it some leeway. I (...) (18 years ago, 12-Dec-08, to lugnet.cad)
| | | Re: Colinear Vertices
|
| (...) triangle has had its surface normal pulled down. So the triangle isn't co-planar with the quad as far as the lighting is concerned. With curve smoothing, all polygons who share a smoothed vertex use a common surface normal for that vertex. But (...) (18 years ago, 13-Dec-08, to lugnet.cad)
|
Message is in Reply To:
| | Re: Colinear Vertices
|
| (...) Not that I know of. I'll think about adding a page to the LDView web site. (I don't think it's really appropriate to add it to ldraw.org, since it's LDView-specific.) (...) The precision is 0.0001. I multiply the coordinate by 10000 and then (...) (18 years ago, 11-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
|
|
|
|
