 Question about edges - Printable Version +- LDraw.org Discussion Forums (https://forums.ldraw.org) +-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html) +--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html) +--- Thread: Question about edges (/thread-8521.html) Pages: 1 2 3 4 Re: Question about edges - Tim Gould - 2013-03-11 Hi Roland, You'll still (admittedly extremely rarely if you set appDef_decCntMul small enough) end up with false negatives from that (see below). Which may not be a problem. Although I suppose that by vounting through twice you could offset by half appDef_decCntMul in the second loop and look and add anything that matches there to your list of matches. Code:```appDef_decCntMul=10000 #1e-4 precision # Before flooring Point1=(0.44499...,0.99434...) Point2=(0.44500...,0.99434...) # floor Point1F=(0.4449,0.9943) Point2F=(0.4450,0.9943) # compare bitwise=(Point1F==Point2F) # is false distance=norm(Point1-Point2) # 1e-5 < Precision```below will avoid false negatives, but give (arguable) false positives... Code:```appDef_decCntMul=10000 #1e-4 precision # Before flooring Point1=(0.44499...,0.99434...) Point2=(0.44500...,0.99434...) # floor Point1F=(0.4449,0.9943) Point2F=(0.4450,0.9943) # round(x) = floor(x+0.5) Point1R=(0.4450,0.9943) Point2R=(0.4450,0.9943) # compare bitwise=(Point1F==Point2F) || (Point1R==Point2R) # is true distance=norm(Point1-Point2) # 1e-5 < Precision``` Tim Re: Question about edges - Tim Gould - 2013-03-11 Hi Ben, Gotcha. No my code won't guarantee transitive points as written, but you can make it guarantee it. Ben Supnik Wrote:For example, if 3 vertices A, B, and C are near each other so that the distance from A to B is < TOL and the distance from B to C is < TOL but the distance from A to C is > TOL, are all three points the same? If not, do we say that A == B and B == C but A != C? :-) My smoothing algorithm assumes transitivity of equality for point locations, so a fuzzy match has to be transitive too. As an experiment, I implemented a simple and stupid grid-snap, which does result in transitive behavior - in the case above, if A, B, and C all snap together, then A == B == C. If the snap separates B and C but keeps A and B together then A == B, A != C, B != C and things are still sane. In SetPointSame(i,j) you'd look through all pairs already set to see if i or j already had a match. So if i1==i2 and i1==i3 then it will set i3==i2. Quote:As an aside, OpenGL (maybe D3D too??) has some pretty specific rules about invariance, water tight meshes, and cracks; if the part library has bit-wise exact transform data and point locations then there will be no mesh cracks, but if that isn't true then I think there could be rendering artifacts..that's why I thought there might be some hope of having bitwise comparable data.* :-) The case that hosed me was a line and triangle not having the same bitwise definitions, which isn't surprising; no one needs watertight rendering between a tri and a line. * For X-Plane we basically require bit-wise exact vertices to get manifold rendering in our model files, because the graphics cards require it...but the output is coming from 3-d modeling programs that more or less do this for free. Thus we ensure the same mathematical function is applied on the same input bits, so while we don't know what the floating point output is, we know it's the same every time. I'd be very surprised if you can ever really guarantee bitwise compatibility with floats after any operations. Even Roland's code cannot do so*. Indeed, if you ever compile with Intel's compilers with warnings on it will highlight every bitwise float match as a potential error. Tim * Although as I note in my comment below that it can be made to do so. Re: Question about edges - Roland Melkert - 2013-03-11 Very interesting, especially since this issue is most likely the reason of the 'crumbled paper' look on some of the parts I'm getting with my current angle only smoothing. I'm going to try these improvements to see if it helps the minifig heads etc. Too bad I won't be able to use the below function of my vector template anymore though Code:`const bool operator==(const TGLVector3 &b) { return memcmp(comp, b.comp, sizeof(TGLVector3))==0; }` comp is the xyz float (or double) array, so memcmp takes only a few clock cycles to compare all three in one go. Up till now one or two extra (almost) identical points where not visible, so I never really tested my code against such requirements, only speed counted It might also be interesting to lower the decimal count precision in these comparisons to 3 instead of 4. Re: Question about edges - Tim Gould - 2013-03-11 Hi Roland, You'll only double the check. I'd be very surprised if it was a limiting factor. Although I admit that my gut instinct could be wrong. For more acceleration, I suggest the following: For each point determine and store (here floora and rounda act as floora(x)=floor(x/tol)*tol and rounda(x)=floor(x/tol+0.5)*tol) Code:```xyzF=floora(xyz) # triplet xyzR=rounda(xyz) # triplet r2F=floor(x*x+y*y+z*z) r2R=floor(x*x+y*y+z*z)```for a comparison you can now do: Code:```if ((r2R==r2R) || (r2F==r2F)) is false, return false else return ((xyzF==xyzF) || (xyzR==xyzR))``` Tim Re: Question about edges - Roland Melkert - 2013-03-12 I did some additional tests, using this very slow but simplifying code: Code:```index=-1; for (int i=0; i 60 degrees _will _be creased. - Two triangles with exact corners and a line covering those corners exactly _will_ be creased. It's easy to use the rules, straight forward to code, etc. cheers Ben Re: Question about edges - Roland Melkert - 2013-03-12 I forgot to mention, only the lower ones use the meta. Normals in the LDraw format would be the best way to go, but like said before editing all existing parts is going to take ages, just look at the timespan BFC is taking. For new parts the combination of >60 deg and matching type 2 lines (I think type 5 don't matter for smoothing) would be a very good and reasonable requirement. Don't get me wrong I'm thankful to the part editors we getting all these parts in whatever form.