Same color overlapping legal? - 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: Same color overlapping legal? (/thread-21900.html) |
Same color overlapping legal? - Tore Eriksson - 2016-11-08 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 RE: Same color overlapping legal? - Willy Tschager - 2016-11-09 (2016-11-08, 22:13)Tore Eriksson Wrote: I'm pretty sure I've asked this before many years ago, but my memory is not getting better. 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. RE: Same color overlapping legal? - Tore Eriksson - 2016-11-09 (2016-11-09, 13:13)Willy Tschager Wrote:(2016-11-08, 22:13)Tore Eriksson Wrote: I'm pretty sure I've asked this before many years ago, but my memory is not getting better. 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. RE: Same color overlapping legal? - Philippe Hurbain - 2016-11-09 Quote: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 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 RE: Same color overlapping legal? - Travis Cobbs - 2016-11-09 Here is pertinent part of the official spec: http://www.ldraw.org/article/512.html#overlaps Specifically, it says: Quote: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. RE: Same color overlapping legal? - Michael Horvath - 2016-11-11 (2016-11-08, 22:13)Tore Eriksson Wrote: I'm pretty sure I've asked this before many years ago, but my memory is not getting better. Overlapping polygons are noticeable in transparent parts in POV-Ray. RE: Same color overlapping legal? - Tore Eriksson - 2016-12-27 (2016-11-09, 18:51)Philippe Hurbain Wrote:Quote: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: 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? RE: Same color overlapping legal? - Tore Eriksson - 2016-12-27 (2016-11-11, 20:50)Michael Horvath Wrote: Overlapping polygons are noticeable in transparent parts in POV-Ray. Yes, I know that. Very relevant in this case. RE: Same color overlapping legal? - Tore Eriksson - 2016-12-28 (2016-12-27, 22:52)Tore Eriksson Wrote:(2016-11-09, 18:51)Philippe Hurbain Wrote: Best of both worlds: low poly count (except for the 8 extra vertices introduced by the two ndis), smooth curves and no overlap: Never mind, I tried dividing it by SQR(0.5) and found out myself. RE: Same color overlapping legal? - tang.dat - Philippe Hurbain - 2016-12-28 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. RE: Same color overlapping legal? - tang.dat - Travis Cobbs - 2016-12-30 (2016-12-28, 7:23)Philippe Hurbain Wrote: 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? RE: Same color overlapping legal? - tang.dat - Philippe Hurbain - 2016-12-30 (2016-12-30, 5:54)Travis Cobbs Wrote:(2016-12-28, 7:23)Philippe Hurbain Wrote: 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. 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. RE: Same color overlapping legal? - tang.dat - Steffen - 2016-12-30 +1 _ RE: Same color overlapping legal? - tang.dat - Travis Cobbs - 2016-12-30 (2016-12-30, 8:29)Philippe Hurbain Wrote:(2016-12-30, 5:54)Travis Cobbs Wrote: Can you refresh my memory about what the tang primitives do? 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). RE: Same color overlapping legal? - tang.dat - Philippe Hurbain - 2016-12-31 (2016-12-30, 23:50)Travis Cobbs Wrote: 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). RE: Same color overlapping legal? - tang.dat - Travis Cobbs - 2017-01-02 (2016-12-31, 10:05)Philippe Hurbain Wrote:(2016-12-30, 23:50)Travis Cobbs Wrote: 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). 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.) RE: Same color overlapping legal? - tang.dat - Philippe Hurbain - 2017-01-02 Thanks, Travis! Is it possible to get a Windows binary including this? RE: Same color overlapping legal? - tang.dat - Travis Cobbs - 2017-01-03 (2017-01-02, 8:27)Philippe Hurbain Wrote: Thanks, Travis! Is it possible to get a Windows binary including this? I'll try to send you a test build. RE: Same color overlapping legal? - tang.dat - Philippe Hurbain - 2017-01-26 (2017-01-03, 2:19)Travis Cobbs Wrote:Works perfectly, as you can see in this image (file here: http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/98138p0k.dat)... what about a public release with this feature?(2017-01-02, 8:27)Philippe Hurbain Wrote: Thanks, Travis! Is it possible to get a Windows binary including this? |