Same color overlapping legal?

[Tore Eriksson]

I'm pretty sure I've asked this before many years ago, but my memory is not getting better.
Is it "legal" to let the polygons in a pattern overlap? Of course you can't allow this with different colors, that would look terrible. If I can use primitives in a pattern instead of handmade polygons, the result will look smoother. But if I can't do it without overlapping, is there any reason to disallow this method? I can't see that it would affect the quality in any way, but that hasn't stopped the leaders of the LDraw community from issuing standards rules before.

Code:

0 Brick  1 x  1 with Blue Bold "0" Pattern
0 Name: 3005pv0.dat
0 Author: Tore Eriksson [Tore_Eriksson]
0 Unofficial LDraw Part

0 BFC CERTIFY CCW

1 16  0 0 0  1 0 0  0 1 0  0 0 1  s\3005s01.dat

1 16  0 13 -10  5.5 0 0  0 0 7  0 1 0  4-4ndis.dat
1 16  0 13 -10  2.3 0 0  0 0 4  0 1 0  4-4disc.dat
1 1  0 13 -10  1.15 0 0  0 0 2  0 1 0  4-4ring2.dat
1 1  0 13 -10  1.5 0 0  0 0 2  0 1 0  4-4ring2.dat
1 1  0 13 -10  1.83333 0 0  0 0 2.33333  0 1 0  4-4ring2.dat

4 16  -10 0 -10  -10 24 -10  -5.5 20 -10  -5.5 6 -10
4 16  -10 24 -10  10 24 -10  5.5 20 -10  -5.5 20 -10
4 16  10 24 -10  10 0 -10  5.5 6 -10  5.5 20 -10
4 16  10 0 -10  -10 0 -10  -5.5 6 -10  5.5 6 -10
0

[Willy Tschager]

I'm pretty sure I've asked this before many years ago, but my memory is not getting better.
Is it "legal" to let the polygons in a pattern overlap? Of course you can't allow this with different colors, that would look terrible. If I can use primitives in a pattern instead of handmade polygons, the result will look smoother. But if I can't do it without overlapping, is there any reason to disallow this method? I can't see that it would affect the quality in any way, but that hasn't stopped the leaders of the LDraw community from issuing standards rules before.

I would hold such a part. When reworking part from the past I remove all these overlapping rings for two reasons:

* Polycount
* Broken mesh which could led to rendering artefacts. Read http://www.ldraw.org/article/218.html#lt4

w.

[Tore Eriksson]

I'm pretty sure I've asked this before many years ago, but my memory is not getting better.
Is it "legal" to let the polygons in a pattern overlap? Of course you can't allow this with different colors, that would look terrible. If I can use primitives in a pattern instead of handmade polygons, the result will look smoother. But if I can't do it without overlapping, is there any reason to disallow this method? I can't see that it would affect the quality in any way, but that hasn't stopped the leaders of the LDraw community from issuing standards rules before.

I would hold such a part. When reworking part from the past I remove all these overlapping rings for two reasons:

* Polycount
* Broken mesh which could led to rendering artefacts. Read http://www.ldraw.org/article/218.html#lt4

w.

Thanks for the pointer. Seems we don't read the same text the same way. "Co-planar polygons (line types 3 and 4) may overlap only if they are the same colour. Any such overlap must be kept to a minimum as it affects the render quality of transparent parts."  As I interpret it, that makes it fully legal and no reason for hold votes. No transperent parts are involved, and polycount has never been an issue before when remaking parts.

But ok, if you prefer poorer quality, I'll keep my better but overlapping version in my private library and submit an egdier for the official.

[Philippe Hurbain]

But ok, if you prefer poorer quality, I'll keep my better but overlapping version in my private library and submit an egdier for the official.

Best of both worlds: low poly count (except for the 8 extra vertices introduced by the two ndis), smooth curves and no overlap:

Code:

0 Brick  1 x  1 with Blue Bold "0" Pattern
0 Name: 3005pv0-2.dat
0 Author: Tore Eriksson [Tore_Eriksson]
0 Unofficial LDraw Part

0 BFC CERTIFY CCW

1 16  0 0 0  1 0 0  0 1 0  0 0 1  s\3005s01.dat

1 16 0 13 -10 5.5 0 0 0 0 7 0 1 0 4-4ndis.dat
1 16 0 13 -10 2.3 0 0 0 0 4 0 1 0 4-4disc.dat
1 1 0 13 -10 2.3 0 0 0 0 4 0 1 0 4-4ndis.dat
1 1 0 13 -10 3.88909 0 3.88909 -4.94975 0 4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 -3.88909 0 3.88909 4.94975 0 4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 3.88909 0 -3.88909 -4.94975 0 -4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 -3.88909 0 -3.88909 4.94975 0 -4.94975 0 1 0 1-4chrd.dat
4 16 -10 0 -10 -10 24 -10 -5.5 20 -10 -5.5 6 -10
4 16 -10 24 -10 10 24 -10 5.5 20 -10 -5.5 20 -10
4 16 10 24 -10 10 0 -10 5.5 6 -10 5.5 20 -10
4 16 10 0 -10 -10 0 -10 -5.5 6 -10 5.5 6 -10
4 1 -3.8891 8.0503 -10 -2.3 9 -10 2.3 9 -10 3.889 8.0503 -10
4 1 3.889 8.0503 -10 2.3 9 -10 2.3 17 -10 3.889 17.9497 -10
4 1 -3.8891 17.9497 -10 3.889 17.9497 -10 2.3 17 -10 -2.3 17 -10
4 1 -3.8891 8.0503 -10 -3.8891 17.9497 -10 -2.3 17 -10 -2.3 9 -10

1-4chrd (or 1-8chrd if you need more leeway) is a powerful tool!

Note that here the ring is thick enough so that this simpler solution also works:

Code:

0 Brick  1 x  1 with Blue Bold "0" Pattern
0 Name: 3005pv0.dat
0 Author: Tore Eriksson [Tore_Eriksson]
0 Unofficial LDraw Part

0 BFC CERTIFY CCW

1 16  0 0 0  1 0 0  0 1 0  0 0 1  s\3005s01.dat

1 16  0 13 -10  5.5 0 0  0 0 7  0 1 0  4-4ndis.dat
1 16  0 13 -10  2.3 0 0  0 0 4  0 1 0  4-4disc.dat
1 1 0 13 -10 2.3 0 0 0 0 4 0 1 0 4-4ndis.dat
1 1  0 13 -10  5.5 0 0  0 0 7  0 1 0  1-4chrd.dat
1 1  0 13 -10  -5.5 0 0  0 0 7  0 1 0  1-4chrd.dat
1 1  0 13 -10  5.5 0 0  0 0 -7  0 1 0  1-4chrd.dat
1 1  0 13 -10  -5.5 0 0  0 0 -7  0 1 0  1-4chrd.dat
4 16  -10 0 -10  -10 24 -10  -5.5 20 -10  -5.5 6 -10
4 16  -10 24 -10  10 24 -10  5.5 20 -10  -5.5 20 -10
4 16  10 24 -10  10 0 -10  5.5 6 -10  5.5 20 -10
4 16  10 0 -10  -10 0 -10  -5.5 6 -10  5.5 6 -10
0
3 1 -2.3 9 -10 0 6 -10 -5.5 13 -10
3 1 -2.3 17 -10 -5.5 13 -10 0 20 -10
3 1 2.3 17 -10 0 20 -10 5.5 13 -10
3 1 2.3 9 -10 5.5 13 -10 0 6 -10
3 1 -2.3 9 -10 2.3 9 -10 0 6 -10
3 1 5.5 13 -10 2.3 9 -10 2.3 17 -10
3 1 -2.3 17 -10 0 20 -10 2.3 17 -10
3 1 -5.5 13 -10 -2.3 17 -10 -2.3 9 -10

[Travis Cobbs]

Here is pertinent part of the official spec:

http://www.ldraw.org/article/512.html#overlaps

Specifically, it says:

Every effort must be made to remove overlapping co-planar polygons (line type 3 or 4). Where overlapping polygons are unavoidable, the overlap must be kept to the absolute minimum.

[Michael Horvath]

I'm pretty sure I've asked this before many years ago, but my memory is not getting better.
Is it "legal" to let the polygons in a pattern overlap? Of course you can't allow this with different colors, that would look terrible. If I can use primitives in a pattern instead of handmade polygons, the result will look smoother. But if I can't do it without overlapping, is there any reason to disallow this method? I can't see that it would affect the quality in any way, but that hasn't stopped the leaders of the LDraw community from issuing standards rules before.

Code:

0 Brick  1 x  1 with Blue Bold "0" Pattern
0 Name: 3005pv0.dat
0 Author: Tore Eriksson [Tore_Eriksson]
0 Unofficial LDraw Part

0 BFC CERTIFY CCW

1 16  0 0 0  1 0 0  0 1 0  0 0 1  s\3005s01.dat

1 16  0 13 -10  5.5 0 0  0 0 7  0 1 0  4-4ndis.dat
1 16  0 13 -10  2.3 0 0  0 0 4  0 1 0  4-4disc.dat
1 1  0 13 -10  1.15 0 0  0 0 2  0 1 0  4-4ring2.dat
1 1  0 13 -10  1.5 0 0  0 0 2  0 1 0  4-4ring2.dat
1 1  0 13 -10  1.83333 0 0  0 0 2.33333  0 1 0  4-4ring2.dat

4 16  -10 0 -10  -10 24 -10  -5.5 20 -10  -5.5 6 -10
4 16  -10 24 -10  10 24 -10  5.5 20 -10  -5.5 20 -10
4 16  10 24 -10  10 0 -10  5.5 6 -10  5.5 20 -10
4 16  10 0 -10  -10 0 -10  -5.5 6 -10  5.5 6 -10
0

Overlapping polygons are noticeable in transparent parts in POV-Ray.

[Tore Eriksson]

But ok, if you prefer poorer quality, I'll keep my better but overlapping version in my private library and submit an egdier for the official.

Best of both worlds: low poly count (except for the 8 extra vertices introduced by the two ndis), smooth curves and no overlap:

Code:

1 1 0 13 -10 3.88909 0 3.88909 -4.94975 0 4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 -3.88909 0 3.88909 4.94975 0 4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 3.88909 0 -3.88909 -4.94975 0 -4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 -3.88909 0 -3.88909 4.94975 0 -4.94975 0 1 0 1-4chrd.dat

Wow, that's awesome! I knew there must be some use for those chrd primitives, but I just couldn't figure out what. Could you please explain how you calculated those nubers, 3.88909 and 4.94975, or is there some tutorial page covering chrds?

[Tore Eriksson]

Overlapping polygons are noticeable in transparent parts in POV-Ray.

Yes, I know that. Very relevant in this case.

[Tore Eriksson]

Best of both worlds: low poly count (except for the 8 extra vertices introduced by the two ndis), smooth curves and no overlap:

Code:

1 1 0 13 -10 3.88909 0 3.88909 -4.94975 0 4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 -3.88909 0 3.88909 4.94975 0 4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 3.88909 0 -3.88909 -4.94975 0 -4.94975 0 1 0 1-4chrd.dat
1 1 0 13 -10 -3.88909 0 -3.88909 4.94975 0 -4.94975 0 1 0 1-4chrd.dat

Wow, that's awesome! I knew there must be some use for those chrd primitives, but I just couldn't figure out what. Could you please explain how you calculated those nubers, 3.88909 and 4.94975, or is there some tutorial page covering chrds?

Never mind, I tried dividing it by SQR(0.5) and found out myself.

[Philippe Hurbain]

Speaking of this kind of issue.... Is there any chance to see tang.dat primitives supported by LDView primitive substitution? That would help when there is no room enough to use a ndis primitive.

[Travis Cobbs]

Speaking of this kind of issue.... Is there any chance to see tang.dat primitives supported by LDView primitive substitution? That would help when there is no room enough to use a ndis primitive.

Can you refresh my memory about what the tang primitives do?

[Philippe Hurbain]

Speaking of this kind of issue.... Is there any chance to see tang.dat primitives supported by LDView primitive substitution? That would help when there is no room enough to use a ndis primitive.

Can you refresh my memory about what the tang primitives do?

It fills the surface between the intersection points of tangents of ideal circle at 16-sided polygon vertices and  "polygonal circle" at current resolution. Can also be considered as a 16-sided ndis. 
As I write this I realize that LDView substitution step is 8, not 16, so we should probably use that resolution. More bulky, but still much less than ndis.

[Steffen]

+1



_

[Travis Cobbs]

Can you refresh my memory about what the tang primitives do?

It fills the surface between the intersection points of tangents of ideal circle at 16-sided polygon vertices and  "polygonal circle" at current resolution. Can also be considered as a 16-sided ndis. 
As I write this I realize that LDView substitution step is 8, not 16, so we should probably use that resolution. More bulky, but still much less than ndis.

Since the *tang primitives are already official, you can't really change them to be based on an 8-sided circle, can you? It's true that LDView wouldn't be able to create substitutions at its lowest primitive setting of 8, and having the tang primitives work with an 8-sided primitive would be nice, but it doesn't seem like something that can be done now. I'll investigate supporting this primitive. It doesn't appear to be very difficult (although supporting it in POV export where it's most useful may or may not be hard).

[Philippe Hurbain]

Since the *tang primitives are already official, you can't really change them to be based on an 8-sided circle, can you? It's true that LDView wouldn't be able to create substitutions at its lowest primitive setting of 8, and having the tang primitives work with an 8-sided primitive would be nice, but it doesn't seem like something that can be done now. I'll investigate supporting this primitive. It doesn't appear to be very difficult (although supporting it in POV export where it's most useful may or may not be hard).

As you say, we could live with this (currently we already have the 1-16chrd and the 4-4ering primitives that don't play well with odd primitive substitution notches). Or we could obsoletize current tang primitives (used by very few parts anyway, only two AFAIK).

[Travis Cobbs]

Since the *tang primitives are already official, you can't really change them to be based on an 8-sided circle, can you? It's true that LDView wouldn't be able to create substitutions at its lowest primitive setting of 8, and having the tang primitives work with an 8-sided primitive would be nice, but it doesn't seem like something that can be done now. I'll investigate supporting this primitive. It doesn't appear to be very difficult (although supporting it in POV export where it's most useful may or may not be hard).

As you say, we could live with this (currently we already have the 1-16chrd and the 4-4ering primitives that don't play well with odd primitive substitution notches). Or we could obsoletize current tang primitives (used by very few parts anyway, only two AFAIK).

I have added support for this in my dev code. Unfortunately, all odd-numbered primitive resolutions in LDView don't work properly for this primitive*. Consequently, I have it round up to the next even numbered resolution for this primitive, which means that if you select an odd-numbered entry, this primitive will get rendered with a higher resolution setting than the others. This doesn't effect POV export, because POV export uses actual circles (effectively infinite curve resolution).

* If you look at the primitive resolution slider in LDView, you can count the notches, starting at 1 on the left. Whatever notch you select, if you multiply that by 8, you end up with the actual number of sided used by LDView to render a full circle for that setting. Unfortunately, any number of sides not evenly divisible by the 4 segments of the base LDraw primitive don't work, since the curve points then don't meet the mid points of the lines between the four external points in the primitive. (This is hard to explain, but trust me, it doesn't work, and I'm not going to try to figure out how to fill it in.)

[Philippe Hurbain]

Thanks, Travis! Is it possible to get a Windows binary including this?

[Travis Cobbs]

Thanks, Travis! Is it possible to get a Windows binary including this?

I'll try to send you a test build.

[Philippe Hurbain]

Thanks, Travis! Is it possible to get a Windows binary including this?

I'll try to send you a test build.

Works perfectly, as you can see in this image (file here: http://www.ldraw.org/cgi-bin/ptdetail.cg...138p0k.dat)... what about a public release with this feature?