(10 hours ago)Rene Rechthaler Wrote: (how does prim subst work exactly? is there like an table which to use for what situation?)
LDView's primitive substitution performs hard-coded primitive recognition based on recognizing patterns in p filenames. Once a file is recognized as being a primitive, the substitution happens in different ways depending on if it is being used for rendering or POV export.
For rendering, I have specialized code that generates the geometry (typically triangles) at the current primitive substitution quality level and based on information extracted from the filename. For aring primitives, the only data that needs to be extracted is the fraction, since they are always high-res (48). Since my initial work assumed that aring would be used next to 16-sided geometry, it just generates an appropriate set of chords. The other case will require me to figure out the appropriate geometry to adapt a low-resolution curved primitive to a high-resolution curved primitive. For curve quality above a certain threshold, both resolutions are the same, so there would be no generated geometry. Below that threshold, I have to figure out how to fill in the gap algorithmically.
For POV export, the goal is the same, but the details are different. Curved primitives in POV generally have to be created using constructive solid geometry with various POV geometric primitives. This is often more difficult to figure out, but the end result is the same. For an aring that adapts a low-resolution curved primitive to a high-resolution curved primitive in POV, there is no geometry, since POV curves don't use triangles. They are all logically infinite resolution. For the other case, it would need to generate the appropriate chords, except for my next paragraph.
Given what is being said, I think that aring should be forbidden to be used to adapt 16-sided geometry, and should only be used for primitive-to-primitive adaptation. Furthermore, if the proposed new primitive is created, it should be created using the existing chrd primitives. By doing it that way, no new primitive substitution code is needed in LDView to have it work. Existing parts that use aring to adapt 16-sided geometry would have to be updated to use the new primitive. (Or if it is decided that part authors should just use chrd primitives directly, then they should be update to do that. Personally, it seems like doing it that way introduces extra work for part authors.)